System and method for normalizing job properties

ABSTRACT

This disclosure provides a system and method for normalizing job properties. In one embodiment, a job manager is operable to identify a property of a job, with the job being associated with an operating environment. The job manager is further operable to normalize the property of the job and present the normalized property of the job to a user.

RELATED APPLICATION

This application claims the priority under 35 U.S.C. §119 of provisionalapplication Ser. No. 60/590,405 filed Jul. 22, 2004.

TECHNICAL FIELD

This disclosure generally relates to enterprise job scheduling and, morespecifically, to a system and method for normalizing job properties.

BACKGROUND

There are numerous heterogeneous operating environments for jobs,applications or other processes. Typically, each of these operatingenvironments comprise one of disparate operating systems including UNIX,Windows or Windows Server, Linux, z/OS or other mainframe OS, andothers. Generally, these jobs or applications, whether enterprise orconsumer, are compatible or optimized for one of these heterogeneousoperating systems. Some properties of these jobs are similar across theheterogeneous systems, while others are unique to each operating system,job type, or job dependencies. For example, the status property of a jobresiding in an enterprise job scheduler for a mainframe system mayindicate one of the following example states: “Abend,” “Requeued,” “JCLError,” and others. But the status of a second job residing in anenterprise job scheduler for a Unix-based system may indicate one of thefollowing example states: “Exited,” “Running,” “Suspended,” “Failed,”and such.

SUMMARY

This disclosure provides a system and method for normalizing jobproperties. In one embodiment, a job manager is operable to identify aproperty of a job, with the job being associated with an operatingenvironment. The job manager is further operable to normalize theproperty of the job and present the normalized property of the job to auser. In one example, the property is a status property and thenormalized status property is selected from one of the following:running; failure; waiting; success; cancel; restart; on hold; late tostart; running late; inactive; and unknown.

In certain embodiments, the property is a first property, the job is afirst job, and the operating environment is a first operatingenvironment. In these embodiments, the job manager is further operableto identify a second property of a second job based on (for example) thesame request from the user, with the second job associated with a secondoperating environment. The job manager may be further operable tonormalize the second property of the second job and present thenormalized second property of the second job to the user.

The details of one or more embodiments of the disclosure are set forthin the accompanying drawings and the description below. Particularfeatures, objects, and advantages of the disclosure will be apparentfrom the description and drawings and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 illustrates a heterogeneous job management system in accordancewith one embodiment of the present disclosure;

FIGS. 2A-E illustrate various configurations of an enterprise system forexecuting jobs in heterogeneous operating environments;

FIG. 3 illustrates one embodiment of the job manager of FIG. 1;

FIG. 4 illustrates an example job object and job property object inaccordance with one embodiment of the present disclosure;

FIGS. 5A-F are example displays for presenting various normalizedproperties of heterogeneous jobs as executed in the system of FIG. 1 inaccordance with one embodiment of the present disclosure;

FIG. 6 is a flowchart illustrating an example method for processing ajob request in one of a plurality of heterogeneous environments inaccordance with one embodiment of the present disclosure; and

FIG. 7 is a flowchart illustrating an example method for normalizing jobproperties in response to a user request in accordance with oneembodiment of the present disclosure.

DETAILED DESCRIPTION

FIG. 1 illustrates a job management system 100 for at least a portion ofenterprise in accordance with one embodiment of the present disclosure.Generally, job management system 100 identifies a property of a job 150associated with one of the plurality of operating environments 106,dynamically normalizes the property of job 150, and presents thenormalized property of job 150 to a user or module. Therefore, jobmanagement system 100 may present information associated with job 150 toa plurality of users in a common way. Put another way, job managementsystem 100 may be operable to provide a consistent view of theinformation to the enterprise. Generally, users may include any user ofsystem 100 or one of its components such as, for example, job schedulingpersonnel with the ability to schedule jobs, forecast future schedulingrequirements, analyze and measure the effectiveness of a job flow,automate job management policies, and/or manage jobs on distributednetworks. Moreover, job management system 100 may perform certainfunctions consistently across disparate or heterogeneous jobs 150. Forexample, heterogeneous jobs 150 may be sorted using one or more of thenormalized properties. In another example, statistics or metrics may begathered or determined based on the value of normalized properties. Incertain embodiments, this normalization of jobs and associatedproperties may be customized according to the particular, user group,department, job type, and such. This customization may be securelyperformed through a web interface by the user or a job or networkadministrator.

At a high level, system 100 is all or a portion of the enterprise thatincludes or is communicably coupled with server 102, one or more clients104, and a plurality of heterogeneous operating environments 106. Forexample, system 100 may be associated with the entire enterprise, ageographical or logical location within the enterprise, or any otherportion of the enterprise. It will be understood that the enterprise maybe a corporation, non-profit organization, government agency, or anyother person or entity that includes, utilizes, or receives the resultsfrom multiple computing devices and operating environments 106. In otherwords, job management system 100 is typically a distributedclient/server system that allows users of clients 104 to submit jobs 150for execution on any of the plurality of operating environments 106. Butsystem 100 may be any other suitable environment without departing fromthe scope of this disclosure. Generally, “dynamically,” as used herein,means that certain processing is determined, at least in part, atrun-time based on one or more variables. Whereas the term“automatically,” as used herein, generally means that appropriateprocessing is substantially performed by at least part of job managementsystem 100. It should be understood that “automatically” furthercontemplates any suitable administrator or other user interaction withsystem 100 without departing from the scope of this disclosure.

Returning to the illustrated embodiment, system 100 includes, invokes,executes, references, or is communicably coupled with a pluralityoperating environments 106. Each operating environment 106 is any systemor subsystem operable to at least partially or fully execute or processjobs 150. For example, each operating environment 106 is one of aplurality of heterogeneous environments including Unix, Linux, Windows,or mainframe environments, as well as others. In another example, anoperating environment 106 may represent a particular application.Moreover, each operating environment 106 may include one server or maybe distributed across a plurality of computers. For example, illustratedsystem 100 includes three operating environments 106 a, 106 b, and 106 crespectively. In this example, first operating environment 106 a isserver environment executing UNIX, second operating environment 106 b isa mainframe environment executing z/OS, and third operating environmentis a distributed processing environment including a plurality of clientsexecuting Windows. In another example, two operating environments 106may be executing the same operating system, but may include differentstorage capabilities, file systems, or computing devices. In yet anotherexample, two operating environments 106 may be substantively similar oridentical, except for executing two disparate cyclical releases orversions of the same operating system. As illustrated in FIGS. 2A-E,each operating environment 106 typically includes one or more jobschedulers 137, each of which may be tailored to, designed for, or atleast partially compatible with job executing in the associatedoperating environment 106. In this case, “operating environment 106” and“job scheduler 137” may be used interchangeably as appropriate. Ofcourse, illustrated operating environments 106 are for example purposesonly. Indeed, while illustrated separately, server 102 may represent,include, or execute one of the operating environments 106 or one of theoperating environments 106 may include or utilize server 102 withoutdeparting from the scope of the disclosure.

Illustrated server 102 includes memory 120 and processor 125 andcomprises an electronic computing device operable to receive, transmit,process and store data associated with system 100. For example, server102 may be any computer or processing device such as, for example, ablade server, general-purpose personal computer (PC), Macintosh,workstation, Unix-based computer, or any other suitable device.Generally, FIG. 1 provides merely one example of computers that may beused with the disclosure. For example, although FIG. 1 illustrates oneserver 102 that may be used with the disclosure, server 102 can beimplemented using computers other than servers, as well as a serverpool. Server 102 may be adapted to execute any operating systemincluding Linux, UNIX, Windows Server, z/OS or any other suitableoperating system. But, the present disclosure contemplates servers otherthan general purpose computers as well as servers without conventionaloperating systems. According to one embodiment, server 102 may alsoinclude or be communicably coupled with a web server and/or a dataserver.

Memory 120 may include any memory or database module and may take theform of volatile or non-volatile memory including, without limitation,magnetic media, optical media, random access memory (RAM), read-onlymemory (ROM), removable media, or any other suitable local or remotememory component. In this embodiment, illustrated memory 120 includesjob objects 140 and normalization policies 145, but may also include anyother appropriate data such as a job history, a security or audit log,print or other reporting files, HTML files or templates, and others. Jobobjects 140 are representations of enterprise jobs and their associatedproperties. These jobs may be update or report batch jobs, databaseprocessing, commands, or other tasks. Each job object 140 typicallycomprises at least a mapping of property names to values that representthe parameters, variables, output format, or other details of theassociated job. For example, job object 140 typically comprises at leasta job identifier and a pointer or other reference to the appropriate orassociated operating environment 106. The environment pointer may beautomatically, dynamically, or manually populated based on operatingsystem compatibility, data storage location, utilization, priority,department or business rules, geography, other criteria orcharacteristics, or any combination thereof. In another example, eachjob object may include job predecessor, job successor, triggers,calendar, VRM requirements, dataset predecessors, user requirements, andnetwork predecessors. In certain embodiments, the constituent data maybe dynamically populated based on the particular type of job. Forexample, in the case of a distributed job, job object 140 may includetwo or more identifiers of the associated operating environments, whilea standalone job merely includes one environment pointer. Job object 140may be in any appropriate logical or physical format including anexecutable, a Java object, text, SQL, XML, and such. Indeed, job object140 may be a default job or a particular instance of a job asappropriate. Moreover, job object 140 may be keyed on or associated witha user, a user or security group, a department, or any other variable orproperty. As described in more detail below, job object 140 may includeany properties operable to be normalized.

Normalization policies 145 include any parameters, variables,algorithms, instructions, rules, records, objects or other policycomponents for normalizing processing. For example, normalizationpolicies 145 may include an enterprise-wide or a default normalizationpolicy 145, thereby providing a consistent view of job properties andinformation. In another example, normalization policies 145 may alsostore a plurality of individual user normalization policies 145, each ofwhich may be associated with a user and allowing the particular user tocustomize or overwrite the enterprise normalization. In one embodiment,normalization policies 145 may comprise one or more tables stored in arelational database described in terms of SQL statements or scripts. Inanother embodiment, normalization policies 145 may store or definevarious data structures such as Java objects, text files, extensibleMarkup Language (XML) documents, Virtual Storage Access Method (VSAM)files, flat files, Btrieve files, comma-separated-value (CSV) files,internal variables, or one or more libraries. In short, normalizationpolicies 145 may comprise one table, file or object or a plurality oftables, files or objects stored on one computer or across a plurality ofcomputers in any appropriate format. Moreover, normalization policies145 may be local or remote without departing from the scope of thisdisclosure and store any type of appropriate data.

Server 102 also includes processor 125. Processor 125 executesinstructions and manipulates data to perform the operations of server102 such as, for example, a central processing unit (CPU), a blade, anapplication specific integrated circuit (ASIC), or a field-programmablegate array (FPGA). Although FIG. 1 illustrates a single processor 125 inserver 102, multiple processors 125 may be used according to particularneeds and reference to processor 125 is meant to include multipleprocessors 125 where applicable. In the illustrated embodiment,processor 125 executes job manager 130, which performs at least aportion of the management of heterogeneous jobs 150 and/or thenormalization of their properties.

Job manager 130 typically comprises any software component operable toallow users access to operating environments 106, submit jobs 150, querythe status or other job properties' normalize some or all of theseproperties, or any other appropriate job management processing. As usedherein, software generally includes any appropriate combination ofsoftware, firmware, hardware, and/or other logic. For example, jobmanager 130 may be written or described in any appropriate computerlanguage including C, C++, C#, Java, J#, Visual Basic, assembler, Perl,any suitable version of 4GL, another language, or any combinationthereof. It will be understood that while job manager 130 is illustratedin FIG. 1 as a single multi-tasked module, the features andfunctionality performed by this engine may be performed by multiplemodules. For example, job manager 130 may be a job scheduler and aplurality of adapters 135 (see FIG. 2). In another example, job manager130 may comprise a connection listener 304, a request controller 308communicably coupled with a plurality of job parsers and managers, aview controller 314, a session manager 318, a template manager 320, anadapter manager 322, and a profile manager 324 (as shown in more detailin FIG. 3). Further, while illustrated as internal to server 102, one ormore processes associated with job manager 130 may be stored,referenced, or executed remotely such as GUI 116 and one or more agentsresiding in the appropriate operating environments 106. Moreover, jobmanager 130 may be a child or sub-module of another software module (notillustrated) without departing from the scope of this disclosure. Incertain embodiments, job manager 130 may include or be communicablycoupled with an administrative workstation 104 or graphical userinterface (GUI) through interface 114. In these embodiments, job manager130 may run as a persistent process (e.g., a daemon or service) operableto listen on a particular port through or in interface 114.

Server 102 may also include interface 114 for communicating with othercomputer systems, such as clients 104, over network 112 in aclient-server or other distributed environment. In certain embodiments,server 102 receives job submissions or customizations from internal orexternal senders through interface 114 for storage in memory 120 and/orprocessing by processor 125. Generally, interface 114 comprises logicencoded in software and/or hardware in a suitable combination andoperable to communicate with network 112. More specifically, interface114 may comprise software supporting one or more communicationsprotocols associated with communications network 112 or hardwareoperable to communicate physical signals.

Network 112 facilitates wireless or wireline communication betweencomputer server 102 and any other local or remote computer, such asclients 104. Illustrated network 112 comprises two sub-nets or virtualLANS, 112 a and 112 b, respectively. Indeed, while illustrated as twonetworks, network 112 may be a continuous network without departing fromthe scope of this disclosure, so long as at least portion of network 112may facilitate communications between job manager 130 and one or more ofthe operating environments 106. In other words, network 112 encompassesany internal or external network, networks, sub-network, or combinationthereof operable to facilitate communications between various computingcomponents in system 100. Network 112 may communicate, for example,Internet Protocol (IP) packets, Frame Relay frames, AsynchronousTransfer Mode (ATM) cells, voice, video, data, and other suitableinformation between network addresses. Network 112 may include one ormore local area networks (LANs), radio access networks (RANs),metropolitan area networks (MANs), wide area networks (WANs), all or aportion of the global computer network known as the Internet, and/or anyother communication system or systems at one or more locations.

Client 104 is any local or remote computing device operable to receivejob submissions 150 and present output (such as properties or reports)via a GUI 116. At a high level, each client 104 includes at least GUI116 and comprises an electronic computing device operable to receive,transmit, process and store any appropriate data associated with system100. It will be understood that there may be any number of clients 104communicably coupled to server 102. For example, illustrated clients 104include one directly coupled client 104 and two communicably coupledclients to the illustrated server 102. Further, “client 104,” “jobowner,” and “user” may be used interchangeably as appropriate withoutdeparting from the scope of this disclosure. Moreover, for ease ofillustration, each client 104 is described in terms of being used by oneuser. But this disclosure contemplates that many users may use onecomputer or that one user may use multiple computers to submit or reviewjobs 150 via GUI 116. As used in this disclosure, client 104 is intendedto encompass a personal computer, touch screen terminal, workstation,network computer, kiosk, wireless data port, wireless or wireline phone,personal data assistant (PDA), one or more processors within these orother devices, or any other suitable processing device or computer. Forexample, client 104 may comprise a computer that includes an inputdevice, such as a keypad, touch screen, mouse, or other device that canaccept information, and an output device that conveys informationassociated with the operation of server 102 or clients 104, includingdigital data, visual information, or GUI 116. Both the input device andoutput device may include fixed or removable storage media such as amagnetic computer disk, CD-ROM, or other suitable media to both receiveinput from and provide output to users of clients 104 through thedisplay, namely GUI 116.

GUI 116 comprises a graphical user interface operable to allow the userof client 104 to interface with at least a portion of system 100 for anysuitable purpose. Generally, GUI 116 provides the user of client 104with an efficient and user-friendly presentation of data provided by orcommunicated within system 100. For example, GUI 116 may be a front-endof job manager 130 and provide functionality to monitor jobs and alerts,as well as a summary of the jobs and alerts. GUI 116 may provide analternate to a Business Scheduling View (BSV) graphical interface formonitoring. Further, GUI 116 may help the user by providing certainadvantages including ease-of-use, compatibility with Java and non-Javabrowser platforms, and performance. Conceptually, the user logs into jobmanager 130 through GUI 116, which then presents a list of jobschedulers. By selecting a particular job scheduler, GUI 116 displaysthe list of active jobs on that scheduler with the appropriatenormalized or raw properties. Using GUI 116, the user can define filtersin order to configure his (or his group's) view to a specific set ofjobs and/or job properties. After configuration, the user can save thisview for later reuse. When a view is saved for later use, it may show upon a list of available, pre-configured views during login. This featuremay give the user the ability to quickly see the same type ofinformation from where he left off last time. Alternatively, the usercan start on a new view by selecting from the list of job schedulers inthe view. From an example “Job Status” view, the user can select a job150 and zoom into its details, thereby easily locating or viewing thespecific properties for each desired job 150. The user can also managejob 150 using this particular view of GUI 116. For example, the user canstart, stop, or suspend the job, often according to the particular jobscheduler 137 capabilities. In addition to the Job Status view, GUI 116may provide “Alert” and “Dashboard” views. The example Alert view mayshow alerts that have been generated by job manager 130 or job scheduler137 in response to a particular filter. The example Dashboard view mayprovide a statistical summary of the jobs and alerts. Moreover, thefilters may be applied in the Dashboard view to set the overall severitylevel of the view. When multiple filters are applied to the Job Status,Alert, or Dashboard views, information from various heterogeneous jobschedulers may be collected into one view. This view shows the selectedjob and all its direct dependencies including its immediatepredecessors, successors, triggers, resource and other requirements, andthe current status of each. The consolidated data is often presented ina single way in an example “Enterprise” view. Thus, the Job Status,Alert and Dashboard views (as well as others) may be types or childrenof certain Enterprise views. Another view may be a Map view, whichgraphically displays the details of a selected job or jobset. Yetanother view may be a Server Configuration view, in which theadministrator or other user can add, edit, and delete servers oroperating environments 106 that are available to job manager 130. Thisview does not typically create back-end servers. Instead, it creates orpopulates the configuration information to access the environments 106based on information supplied by the user. Of course, this configurationinformation may be automatically retrieved, received, or polled asappropriate. Of course, each view may be static and or dynamic asappropriate. Generally, static views do not change while displayed,while dynamic views automatically change at a regular update interval ordynamically update according to other criteria. In certain embodiments,GUI 116 may also present a Credentialed User view, allowing the user oradministrator to add, edit, and delete Credentialed Users. TheCredentialed User information provides login credentials to back-endservers or operating environments 106. Credentialed Users are set up tosimplify access to the back-end servers/environments 106 and to providean additional level of security. The portal user ID may be used as a keyto access the credentialed user information. In addition to the portaluser ID, the system administrator can set an environment password, whichcan be different than the Portal password. This feature is for users whohave access to multiple back-end servers with the same user ID butdifferent passwords for each. In addition, for each user ID in thecredentialed user information, an alias ID can be set up. The alias IDcan be either a group ID (one-to-many or many-to-one) or can be a user'spersonal ID for the back-end server. The alias ID has an associatedpassword for the back-end server. In addition, a group user/group ID canbe set to provide the credentials.

Regardless of the particular view or data, GUI 116 may comprise aplurality of customizable frames or windows having interactive fields,pull-down lists, and buttons operated by the user. In one embodiment,GUI 116 presents normalized information associated with jobs 150,including job status, and associated buttons and receives commands 170from the user of client 104 via one of the input devices. Thisnormalized information may be presented in tabular, graphical, and anyother suitable format. Moreover, it should be understood that the termgraphical user interface may be used in the singular or in the plural todescribe one or more graphical user interfaces and each of the displaysof a particular graphical user interface. Therefore, GUI 116contemplates any graphical user interface, such as a generic web browseror touch screen, that processes information in system 100 andefficiently presents the results to the user. Server 102 can accept datafrom client 104 via the web browser (e.g., Microsoft Internet Exploreror Netscape Navigator) and return the appropriate HTML or XML responsesusing network 112. For example, server 102 may receive a job submissionfrom client 104 using the web browser, execute the particular job 150 inthe appropriate operating environment 106, and present the results inthe web browser.

In one aspect of operation, a user logs into job manager 130 using GUI116 and is presented with the following example functionality or views:Administration, Monitoring, Configuration, and Event Management. Boththe Administration and Monitoring views normally includes an appletdeployed in an HTML page. The Configuration view is provided by a seriesof HTML pages that communicate with a Configuration servlet or process.The applets graphically display the objects defined in the jobmanagement system. The applet communicates with the appropriate servletor process to send and receive data to the job management system. EventManagement provides web-enabled access to the log facility. Job manager130 may use the Jacada Terminal Emulator (JTE) to provide host emulationcapabilities. In certain embodiments, the user may be provided access tocertain functionality based on assignments to Portal workgroups. Basedon the particular functionality selected by the user, job manager 130may invoke a particular module from a Server/Web Server tier. Thisexample level includes applets, servlets, servlet engines, and adapters.

Each servlet serves as a central point of communication and managementbetween the GUI 116 (Applet and/or Portlet) and the one or moreoperating environments 106. The servlet is generally operable to exposea callable interface to GUI 116 to allow the end-user to configure andmonitor jobs. The servlets, in turn, are operable to forward those callsinto the various adapters that link with the particular environment 106.The servlets may be further operable to control client sessions. Thissession control typically involves session management, authentication,and persistency. As described in more detail in the embodiments of FIG.2, each individual adapter 135 communicates with the servlets and theassociated operating environment 106 and/or job scheduler 137. Adapters135 encapsulate the job calls 150 to the operating environment 106and/or job scheduler 137 and expose an API that the example servlets canuse. In other words, once the user selects the appropriate action totake within one of the desired operating environments 106 (such assubmitting a job using the associated job scheduler 137), theappropriate adapter 135 encapsulates the user command into an object 150appropriate for the particular operating environment 106 and/or jobscheduler 137. After any suitable amount of processing or jobmanagement, job scheduler 137 communicates output or job details to jobmanager 130 via the appropriate adapter 135 (perhaps in response to aquery or automatically upon job completion or error).

At this point, adapter 135 may contain unmodified or native data fromeach job scheduler 137. However, normalization profiles 145 gives theuser, administrator, or job manager 130 the ability to generate, select,or otherwise identify a set of normalized properties to be shown fromthe possible properties of the various types of jobs and operatingenvironments 106. Job manager 130 may then utilize one or morenormalization profiles 145, which in this example includes a pluralityof job status property objects, to normalize the encapsulated jobproperties. Job manager 130 applies the job status property objects oneach set of jobs in the results 160. The outcome of this process is aset of values, for each job, that are ordered and normalized as needed.This information may be displayed in a tabular format at this point forthe convenience of the user using GUI 116. It could also be formatted asan XML document or embedded, included, or otherwise presented usingother outputs. In short, there is no specific limitation on how theresulting set of values may be displayed or stored. There may also be asorting function built into normalization profiles 145, job manager 130,or GUI 116. In this case, after the property objects generate the set ofvalues, the collection can be sorted by selecting a specific normalizedproperty to sort on. Then, using a standard sort capability such as onebuilt into Java, a comparator object can be provided to extract the twoproperty values from each job and compare them. The result of thesorting process is a collection of values that are sorted by the chosenproperty, even when the native values are disparate.

FIGS. 2A-E illustrate various configurations of enterprise system 100for executing jobs in heterogeneous operating environments 106.Generally, these figures illustrate a job manager 130 communicating witha job scheduler 137, resident in one of the operating environments 106,via an associated adapter 135. Put another way, job manager 130 may useadapters 135 to interface, normalize, or otherwise processcommunications from various heterogeneous job schedulers 137.

Each adapter 135 is an object or other module that encapsulates one ormore types of job schedulers 137. Adapters 135 may be written ordescribed in any particular format or programming language. For example,adapter 135 may be a Java object. Regardless of the particular format,adapter 135 is generally operable to provide APIs to job manager 130 forcommunication with each job scheduler 137 to manage and monitor jobinformation. Put another way, adapter 135 may be logically locatedbetween job manager 130 and at least the associated job scheduler 137,thereby allowing job manager to be communicably coupled with the jobscheduler 137. In certain embodiments, each adapter 135 may provide thiscompatibility by invoking, including, exposing, or executing one or moreof the following example methods: Name Description ListgetJobStatus(List filters ) Returns the job status data according to thegiven filters Job getJobDetails(Map params ) Returns the job detailsvoid updateJobDetails(Job job ) Updates the job details List getRunLog(RunLogFilter Returns the run log data filter ) according to the givenfilter List getPriorRun( PriorRunFilter Returns the prior run datafilter ) according to the given filter void actionJob(Job job, MapPerform action on params ) the specified job List getJobPreds(Job job,Map Returns the job predecessors params ) of the specified job ListgetJobVRMs(Job job, Map Returns the job VRMs params ) of the specifiedjob void actionVRM(VRM vrm, Perform action on the Map params ) specifiedjob VRM void actionPred(Pred pred, Map Perform action on the params )specified job predecessor

There may be any number of adapters 135, each compatible with anyappropriate number of job schedulers 137. For example, system 100 mayinclude a mainframe job adapter 135 that provides APIs to allowcommunication with a mainframe-based job scheduler 137. These APIs allowthe caller to read and write to different objects that exist within themainframe job scheduler 137. These objects may include jobs, calendars,datasets, ARFSets, ARFs, JCL, triggers and predecessors. In anotherexample, system 100 may include a distributed job adapter 135 thatprovides APIs to allow communication with a distributed job scheduler137. This example distributed job scheduler 137 may run on anydistributed platform such as Windows and Unix-based operating systems.As with the mainframe adapter 135, the APIs allow the caller to read andwrite to different objects (such as jobs, calendars and globalvariables) that exist within the distributed job scheduler 137.

Job scheduler 137 is any executable, routine, service, daemon, or othermodule or process that is operable to execute, monitor, or otherwisemanage jobs 150 in at least one operating environment 106. Typically,job scheduler 137 is associated with a particular type, format, orcompatibility of job 150. But, as illustrated in the variousembodiments, any job scheduler 137 may be also be configured to run as amore varied job scheduler or even a master job scheduler 137 managing aplurality of slave job schedulers 137. Moreover, while job scheduler 137is illustrated as residing within a particular operating environment106, it will be understood that is for example purposes only and merelyillustrates that job scheduler 137 is associated with the particularenvironment 106. Indeed, job scheduler 137 may be distributed across aplurality of environments, computers, or data stores, without departingfrom the scope of the disclosure. Job scheduler 137 may be proprietary,off-the-shelf, customized, or any other type of job scheduler. Moreover,enterprise 100 may purchase, download, or otherwise obtain job scheduler137 using any appropriate technique.

For example, FIGS. 2A-E illustrates at least a portion of system 100that includes server 102 communicably coupled to first and secondoperating environments 106. In this example, each operating environment106 includes one job scheduler 137, each operable to manage jobs 150 forthat particular operating environment 106. Job manager 130, illustratedas executing on server 102, is communicably coupled to first jobscheduler 137 a through a first adapter 135 a and to second jobscheduler 137 b through a second adapter 135 b. But, as illustrated inthe respective figures, adapters 135 may reside on server 102 and/or theassociated operating environment 106 as appropriate. For example, asillustrated in FIG. 2A, job manager 130 locally includes, loads, orotherwise invokes adapter 135 a for executing job 150 a, receiving orretrieving job status 160 a, or other communications, commands,instructions, and such to first job scheduler 135 a. In another example,as illustrated in FIG. 2B, one or more of the adapters 135 may act as anagent, service, or daemon residing within the operating environment 106for the appropriate job scheduler 137. In this example, job manager 130may invoke or interact with remote adapter 135 using a particular port,socket, or method. In yet another embodiment, illustrated in FIG. 2D,job manager 130 may include one of the job schedulers 137 operable toschedule heterogeneous jobs 150 to a plurality of operating environments106. In this embodiment, job manager 130 may be considered a logicalall-in-one module with internal job scheduling, adapting, andnormalizing processes and capabilities.

As illustrated in FIG. 2E, a particular job scheduler 137 or otherapplication (job manager 130 or other non-illustrated application) maybe designed or implemented as a “metascheduler” (137 a) that caters tomore than one type of job 150 or is compatible with more than oneoperating environment 106. In this scenario, job scheduler 137 a canmanage heterogeneous jobs on different platforms, operating systems, orother environments 106. When job scheduler 137 a provides theinformation about such jobs, it may automatically normalize theproperties of these jobs. As illustrated, the “metascheduler” 137 acould also control subordinate schedulers 137 b and 137 c, respectively.“Metascheduler” 137 a may be operable to consolidate and normalize theinformation obtained from the subordinates 137 b and 137 c asappropriate.

In one aspect of operation, illustrated in example FIG. 2C, whenretrieving the details or properties of jobs, adapter 135 communicateswith job scheduler 137 to get the raw values of these job properties.After adapter 135 receives the information, it then translates andnormalizes certain properties into a common set of values. Inparticular, the status property of job 150 is mapped from the set of jobscheduler-specific values into a common or customized set of values. Insome cases, more than one raw value may be used to map to the common setof values. For example, a mainframe job may include three propertiesthat determine the normalized job status value. These example propertiesare: queue name, status and specific status. In this example, the rawvalues are used in combination to map to a common normalized value.Windows/ Normalized Mainframe Raw Value Unix Raw Value(Queue/Status/Specific Status) Value Running ACT/any status exceptRunning WARN/any specific status Waiting REQ/any status except Starting,Inactive, WARN or ERRX/any specific Activated, Queue status exceptRESTART Wait RDY/any status except WARN/ any specific status SuccessCMP/any status except Success CANCEL/any specific status FailureREQ/ERRX/any specific status Failure REQ/any status/RESTART CancelCMP/CANCEL/any specific status Terminated Restart Late to Start On HoldREQ/WARN/HOLD Hold Late to Start REQ/WARN/any specific statusRDY/WARN/any specific status Running Late ACT/WARN/any specific statusInactive FOR/any status/any specific status Unknown other values orcombinations other valuesIn other words, the normalization of job properties can also beperformed in job manager 130 instead of the associated adapter 135.Indeed, an example Job Status Console of GUI 166 may also be operable tonormalize of the status property of the jobs. That is, adapter 135 mayperform no normalizing translation when the raw data is retrieved fromthe job scheduler 137. This information is then returned to the caller,which is job manager 130 or GUI 116 as appropriate. The callingapplication then normalizes the job properties using, for example, atechnique of mapping the raw values into a set of common values usingnormalization policies 145.

FIG. 3 illustrates one embodiment of the job manager 130. At a highlevel, this embodiment of job manager 130 includes a connection listener304, a request controller 308 communicably coupled with a plurality ofjob parsers and managers, a view controller 314, a session manager 318,a template manager 320, an adapter manager 322, and a profile manager324. But, of course, these sub-modules are for example purposes only andjob manager 130 may include none, some, or all of (as well as other) theillustrated sub-modules. Moreover, one or more of the sub-modules may beremote, dynamically linked, or invoked as appropriate.

Connection listener 304 is any module, library, object, or other processoperable to listen (such as on a known port(s)) for connections fromclients 104. For example, connection listener 304 may include orimplement the following example properties: Name Description portListList of server ports serverSocketList List of server socketsconnectionThreadManager Connection thread manager

Connection listener 304 may also execute or invoke the following examplemethods: Name Description void init( ) Initialize the server listenervoid destroy( ) Destroy the server listener void addPort(int portNumber)Add a listener port void removePort(int portNumber) Remove a listenerport

Connection listener 304 may include or be communicably coupled withconnection pool 302. Connection pool 302 may be any thread managermodule or data structure operable to dispatch outgoing messages to theconnection threads for processing. In certain embodiments, connectionpool 302 is at least partially responsible for maintaining connectionthreads for communications between job manager 130 and clients 104. Thefollowing table shows example properties of connection pool 302: NameDescription threadList List of connection threads workerPool Worker pool

And the following table shows example methods of the connection pool:Name Description void init( ) Initialize the manager void destroy( )Destroy the manager void addConnection(Socket Add a new socketconnection and socket) instantiate a connection thread to handle it voidDestroy the socket connection thread destroyConnection(Socket socket)void sendMessage Send a message to the first (ResponseMessage msg)available connectionAfter a connection is established, it is assigned to a connection threadin the connection pool, for processing communications. Generally, aconnection thread manages a particular connection. For example, theconnection may be keyed on or assigned a socket. For example, when anoutgoing message is to be sent out, the thread sends the message throughthe connection using the appropriate socket. When an incoming request isreceived from client 104, the thread reads the message and unpacks itinto a message object. This object is then handed off to the worker pool306 for processing.

Worker pool 306 is any object or data structure representing the pool ofworker threads. Generally, each worker thread object represents a threadthat can perform a particular task. For example, the worker thread mayaccept a unit of work and perform or execute it. When the task iscompleted, the worker is typically released back into worker pool 306.Worker threads are handed out to perform tasks on behalf of client 104.In certain embodiments, worker pool 306 can be configured to start witha particular number of threads and automatically grow to handle higherloads as necessary. Worker pool 306 may include the following exampleproperties: Name Description workerThreadList List of worker threadsconnectionPool Connection pool

and implement the following example method: Name Description voidprocess( RequestMessage message) Process the given request messageIllustrated worker pool 306 is communicably coupled with requestcontroller 308.

Request controller 308 is any module, object, or other process operableto route incoming messages to the appropriate objects 310 and 312. Forexample, the message may first be sent to the appropriate parser object310 so that the message may be parsed into a request object. There maybe many kinds of request objects, such as one for each type of request.For example, the following table illustrates a number of example requestobjects: Type Parameter Description Server Connect server Name of serveruser User name credential password Password credential Server Disconnectserver Name of server Get Job Status server Name of server view Name ofjob status view Scroll Job Status view Name of job status view scrollsize Scrolling size scroll direction Direction (forward or back) SortJob Status view Name of job status view property Which property toscroll by direction Ascending or descending Save Job Status view Name ofjob status view old view name Previous name of job status view (if any)other parameters Other configuration parameters Delete Job Status viewName of job status view Get Job Details job name Name of job serverServer name job number Job number job properties Other job parametersUpdate Job Details job name Name of job server Server name job numberJob number job properties Other job parameters Job Action job name Nameof job server Server name job number Job number job properties Other jobparameters action properties Action parameters Get Run Log server Servername view View name Save Run Log view View name old view name Previousname of run log view, if any Delete Run Log view Delete the run log viewGet Prior Run server Server name view View name Save Prior Run view Viewname old view name Previous name of prior run view, if any Delete PriorRun view Delete the prior run view Get Alerts server Server name viewView name Update Alerts server Server name view View name alertproperties Alert properties filter properties Filter properties AlertAction alert properties Alert properties action parameters Parameters toalert action Get Dashboard server Server name view View name UpdateDashboard server Server name view View name dashboard propertiesDashboard properties filter properties Filter properties Open sessionCreate new session Close session session ID Destroy session

In certain embodiments, the request object encapsulates data pertinentto the request, including ID, session, request parameters, and more. Forexample, the request object may have the following properties: NameDescription requestId Request ID session Session response Response tothis request, if any

Each request object may implement or invoke the following examplemethods: Name Description int getRequestId( ) Returns the request IDvoid setRequestId( int id ) Sets the request ID Session getSession( )Returns the session void setSession( Session Sets the session session )IResponse getResponse( ) Returns the response associated with thisrequest, if any void setResponse( Sets the response IResponse response )

Based on the incoming message's request ID, a parser manager providesthe appropriate parser object 310 to unpack the message into the requestobject. Parser object 310 is then invoked to unpack the message. It willbe understood that there may be any number of parser objects 310, suchas one for each type of request. For example, the parser manager mayinclude or be coupled with one or more of the following example parserobjects 310: Name Description JobStatusParser Parses requests pertainingto job status JobDetailsParser Parses requests pertaining to job detailsJobActionsParser Parses requests pertaining to job actions ServerParserParses requests pertaining to server actions OEParser Parses requestspertaining to operating environment specific objects AlertParser Parsesrequests pertaining to alerts DashboardParser Parses requests pertainingto dashboard SessionParser Parses requests pertaining to session

These example parser objects 310 may implement, execute, or produce thefollowing request messages: Parser Request Message JobStatusParser GetJob Status Scroll Job Status Sort Job Status Save Job Status Delete JobStatus JobDetailsParser Get Job Details Update Job DetailsJobActionsParser Job Action ServerParser Server Connect ServerDisconnect CA7Parser Get Run Log Save Run Log Delete Run Log Get PriorRun Save Prior Run Delete Prior Run AlertParser Get Alerts Update AlertsAlert Action DashboardParser Get Dashboard Update DashboardSessionParser Open Session Close Session

After the request object is produced by parser object 310, the requestis routed to one of the handler objects 312 for subsequent processing.The handler manager processes a request object, which often includes theobject ID. Based on the request object ID and other information, thehandler manager routes the request object to the correct handler object312. Each handler 312 is responsible for processing the request usingoperating environment 106, adapters 135, and job schedulers 137 asappropriate. As with parser objects 310, there are typically manyhandler objects 312, such as one for each type of request. In certainembodiments, each handler 312 is responsible for performing orrequesting the work that is requested. For example, each handler may beoperable to load, invoke, or communicate with the appropriate adapter135 based on the request object. As a result of its processing, aresponse object is produced. This response object is returned along withthe request object, after processing (typically through adapter 135).The following table shows an example list of handlers 312: NameDescription JobStatusHandler Processes requests pertaining to job statusJobHandler Processes requests pertaining to job details JobHandlerProcesses requests pertaining to job actions ServerHandler Processesrequests pertaining to server actions OEHandler Processes requestspertaining to OE specific objects AlertHandler Processes requestspertaining to alerts DashboardHandler Processes requests pertaining todashboard SessionHandler Processes requests pertaining to the session

The following table maps requests to example handlers: Handler RequestJobStatusHandler Get Job Status Scroll Job Status Sort Job Status SaveJob Status Delete Job Status JobHandler Get Job Details Update JobDetails Job Action OEHandler Get Run Log Save Run Log Delete Run Log GetPrior Run Save Prior Run Delete Prior Run AlertHandler Get Alerts UpdateAlerts Alert Action DashboardHandler Get Dashboard Update DashboardSessionHandler Open session Close sessionAs described above, the processing by each handler object 312 results ina response object. This example response object is then fed into viewcontroller 314 to produce the response that, in turn, is returned as theoutgoing message to client 104.

View controller 314 routes a processed request object (along with itsresponse object, if any) to the correct objects. First, the request isfed to a view manager, which is operable to generate a view for use byGUI 116. The view manager provides, calls, or other executes viewhandlers to process requests into views. For example, it may route therequest to the correct view handler. There are any number of handlerobjects, such as one for each type of view. Name DescriptionJobStatusHandler Processes responses pertaining to job statusJobDetailsHandler Processes responses pertaining to job detailsJobActionsHandler Processes responses pertaining to job actionsServerHandler Processes responses pertaining to server actionsCA7Handler Processes responses pertaining to CA-7 specific objectsAlertHandler Processes responses pertaining to alerts DashboardHandlerProcesses responses pertaining to dashboard

The view manager is responsible for processing the given request into anend-user view. As a result of its processing, a view object is producedor updated. This view object is returned along with the request objectafter processing. After the view is produced, the response object isthen sent back to client 104. It will be understood that the responseobject may comprise any particular data or instruction in any suitableformat. There may be any number of types or sub-classes of responseobjects. For example, Type Property Description Server Connect ServerDisconnect Get Job Status jobStatus Job Status object Scroll Job StatusjobStatus Job Status object Sort Job Status jobStatus Job Status objectSave Job Status jobStatus Job Status object Delete Job Status Get JobDetails job Job object Update Job Details job Job object Job Action jobJob object action returns Other action return values Get Run Log RunLogRun Log object Save Run Log RunLog Run Log object Delete Run Log GetPrior Run PriorRun Prior Run object Save Prior Run PriorRun Prior Runobject Get Alerts alerts Alerts object Update Alerts alerts Alertsobject Alert Action alert Alert object action returns Other actionreturn values Get Dashboard dashboard Dashboard object Update Dashboarddashboard Dashboard object Open session session Session object

In certain embodiments, the response object encapsulates most or all ofthe data pertinent to the response, such as output information, errors,and more. This response object may include some or all of the followingexample properties: Name Description request Request associated withthis response, if any buffer Buffer containing response exceptionException, if any errorMessage Error message, if any errorCode Errorcode, if any

Moreover, in certain embodiments, the response object may include thefollowing example methods: Name Description IRequest getRequest( )Returns the request associated with this response void setRequest(IRequest Sets the request request ) StringBuffer getBuffer( ) Returnsthe response buffer void setBuffer( StringBuffer Sets the responsebuffer buffer )

Illustrated job manager 130 also includes session manager 318. In thisembodiment, session manager 318 is any module generally responsible forhandling sessions. In other words, it creates, stores, and destroyssessions that are assigned to each unique client 104, often utilizing amap of the current sessions. The session typically maintains persistentinformation for a unique client 104 for the lifetime of the connection.Certain back-end objects specific to client 104 are stored and reachablefrom the client's session. In certain embodiments, session manager 318implements the following example methods: Name Description SessioncreateSession( ) Creates a new session void destroySession( Destroy thegiven session Session session ) Session findSession( String Return thesession that matches the given sessionId ) session ID, if any void init() Initialize the session manager void destroy( ) Destroy the sessionmanagerSession manager 318 may automatically cull inactive or abandonedsessions that exceed a timeout period. For example, certain sessions aregoverned by an idle timeout. If this session is kept idle beyond aconfigurable timeout period, then session manager 318 may clean it upautomatically. In this example, all objects—views, models, adapters,etc.—associated with the session are destroyed. A next request by theuser may result in an error indicating an unknown session or badsession. But, if the view is dynamic, then the view may be responsiblefor sending the timeout event at the point where the manager cleans upthe session (and its views).

Template manager 320 may be any module operable to manage templates,which are generally stored as objects in HTML files with placeholdervariables representing dynamic sections. But in certain circumstances,templates may not be complete <html> blocks. Some may represent smallsections of a complete page such as a frame, table, graph, etc. Atruntime, the component sections are typically replaced by the actualdata. Template objects are identified by their file names. Since theyare often uniquely named on the file system, there may be no need toinvent a new tagging scheme to identify them. Once requested, executed,or otherwise located, a transformation of the template yields the outputthat is returned to the user through GUI 116. During startup,initialization, or at any other appropriate time, job manager 130 readsin or loads the desired templates. Templates are often preprocessedafter they are read from the file system. Each template may beencapsulated inside an object that uses a vector. Each entry in thevector contains an internal object that is either a static portion ofthe template or a dynamic portion represented by a variable name. Whenthe entries are traversed in order and printed out, the resulting outputresembles the template file. This process may be called printing. Thetemplate object exposes the printing functionality with a parameter. Thecaller provides a map that contains variable names and values as itsparameter. When the template object encounters a variable name in thevector while printing, it uses the map to resolve the variable name intoa value. That value is then printed in lieu of the variable; otherwise,the variable may be deemed empty. Sometimes, template manager 320executes code in response to a variable entry in the vector. The callercan register callbacks with the object for this scenario. Callbacks canbe registered for specific variable name, index number, or allvariables. Parameters to a callback include the current vector entry andworking buffer of the printing process. Template manager 320 hands theseobjects out to transformers as necessary. Transformers can use the sametemplate object simultaneously. In this scenario, the template object isresponsible for safely supporting multiple callers.

Adapter manager 322 is responsible for handling adapter wrappers, oftenutilizing a map of adapters. The adapter wrapper encapsulates a local orback-end adapter 135. By providing a high-level interface layer on topof each adapter 135, the wrapper provides a consistent and semantic setof methods to each type of job scheduler. Typically, adapter manager 322creates, stores, and destroys wrappers that are assigned to each uniqueback-end connection or environment 106. In certain embodiments, adaptermanager 322 implements the following example methods: Name DescriptionAdapterWrapper Creates or returns the adapter wrapper for getAdapter(String server ) this server void init( ) Initialize the adapter managervoid destroy( ) Destroy the adapter manager

Profile manager 324 is responsible for handling profile objects such as,for example, servers, users, groups and views. In this example, theserver profile object encapsulates a configured server, the user profileobject encapsulates a user record, the group profile object encapsulatesa Portal group record, and the view profile object encapsulates a viewrecord. The profile manager 324 communicates with configuration, Portal,and its own data store to create, update and delete these objects. Incertain embodiments, profile manager 324 includes the following examplemethods: Name Description ServerProfile getServer Returns the serverprofile matching the (String serverName ) given name UserProfilegetUser(String Returns the user profile matching the userName ) givenname GroupProfile getGroup Returns the group profile matching the(String groupName ) given name ViewProfile getView Returns the viewprofile matching the given (String userName, String name, that isaccessible to the user viewName ) List getServers( ) Returns the list ofservers List getUsers( ) Returns the list of users List getGroups( )Returns the list of groups List getViews(String Returns the list ofviews that are accessible username ) to the userIt will be understood that the foregoing sub-modules, properties, andmethods are for illustration purposes only. Indeed, each of thesesub-modules, properties, and methods may or may not be present incertain job managers 130. Put another way, job manager 130 includes anyprocesses or data storage operable manage jobs 150 and may include none,some, or all of the foregoing example embodiments without departing fromthe scope of the disclosure.

In one aspect of operation, a flow describes a path of execution of aclient request through job manager 130. The request typically originatesfrom GUI 116 and results in a new or updated page that is returned tothe browser. When the servlet receives a request, it is routed therequest controller 308. This controller 308 produces a request objectthat encapsulates the HTTP request and response. Request controller 308then forwards this object to parser manager 310. Parser manager 310 iscomprised of one or more parsers. Each parser inspects the request andbreaks it down into various pieces of information as appropriate. Forexample, the session ID and request ID are extracted. The parser may usethis information to look up objects that are relevant to the request.For example, the session ID translates to a session object. When controlreturns to request controller 308 from the parser, the request object isforwarded to handler manager 312.

Handler manager 312 is comprised of one or more handlers. Based oninformation in the request object such as the request ID, handlermanager 312 forwards the request to the corresponding handler. Eachhandler may be considered an “atomic” piece of business logic dedicatedto servicing a request. A handler often depends on other objects toaccomplish its work. Some of these objects include adapters 135, modelobjects, and other manager objects. For example, when a job statushandler executes, it uses the correct adapter instance 135 inconjunction with the job status model object to accomplish its work.When the handler finishes its work, it produces a response object. Aresponse object can contain different pieces of information such asoutput data, error codes, and others. Handler manager 312 returns thisresponse object to request controller 308.

Request controller 308 forwards the response object to view controller314. View controller 314 is comprised of one or more view objects. Eachobject is dedicated to producing a specific view such as job status. Thejob status response object provides the information to the view toproduce the output for the browser. Views are normally closely tied totemplates. Template manager 320 provides HTML templates that form thebasis for the output. The final output is a combination of data from aresponse object and a template. After the output is composed, viewcontroller 314 sends it to client 104. Control then returns to requestcontroller 308 and out of the servlet.

FIG. 4 illustrates an example record or object in normalization policy145 and child or associated job property object in accordance with oneembodiment of the present disclosure. At a high level, normalizationpolicy 145 includes a number of records or objects. For example, onerecord or object (such as a Java job status model object) represents thejob status view for a particular job 150. In certain embodiments, eachobject 145 contains a collection of Job Status Filters 402 andproperties 404. Job Status Filter 402 represents a particular filter inthe view associated with operating environment 106. Job Status Filter402 may implement the filter using any suitable format. For example, JobStatus Filter 402 may be a collection of tuple objects. Each exampletuple object comprises three values: property name, property operator,and property value. The property name contains the name or alias of theproperty that is matched from the job definition or instance. Forexample, the name could be “Job ID” representing the ID number of thejob. The property operator contains the type of comparison to perform onthe property value. For example, the operator could be “=” representingthe “equals” comparison. The property value contains the value to matchor compare. For example, the value could be “100.” In certainembodiments, Job Status Filter 402 may allow multiple property operatorsand/or property values in the same tuple. For example, there could bemultiple values specified in a special format as the property value,such as “100,101,102.” The interpretation of the specification ofmultiple property operators and/or property values in the filter maydepend on the property name in question. In addition to the collectionof tuple objects, Job Status Filter 402 may contain a reference,identifier, or other pointer to an instance of the associated one ormore job schedulers 137. As described above in FIGS. 2A-E, each instanceof a job scheduler 137 may be identified by a machine name, networkaddress, database name, or a combination of system, network, databaseand proprietary identifiers that represent a unique installation of theassociated job scheduler 137 or operating environment 106. Thisreference may later be resolved to the set of information in order toperform a network connection or API call into that instance of a jobscheduler 137. In one aspect of operation, normalization policy 145 isaccessed by first grouping the Job Status Filter objects according totheir references to instances of job schedulers 137. For example, ifthere are three filter objects and two of them refer to “Job SchedulerInstance 1” and the third refers to “Job Scheduler Instance 2,” then twofilter groups may be formed: one for Instance 1, which contains twofilter objects, and another for Instance 2, which contains one filterobject. Then normalization policy 145 distributes each filter group to aunique worker thread for processing. Job manager 130 then waits for thethreads to complete the processing before continuing.

Property 404 includes any job property, status, variable,characteristic, object, or other component operable to include,identify, or reference or a particular of the associated job. For easeof readability, property 404 may be referred to as job status propertyobjects, but this is not meant to limit the scope of the disclosure.Such an example job status property object may have three purposes.First, it represents a specific property of job 150 such as, forexample, the property object may represent the name of job 150. Second,the object may be operable to extract the value of the property that itrepresents from job 150. So, for example, when a property object thatrepresents the name of job 150 is “applied” to a job object that isnamed “Job A,” the result is the value “Job A.” Job status property alsomay convert the value into a normalized format, instead of keeping theunmodified or raw value. This is typically beneficial when jobs 150 fromtwo different types of job schedulers 137 provide different values thatare actually equivalent for the same type of property. For example, aproperty object that represents the status of job 150 may extract twodifferent values from two heterogeneous jobs 150, such as “Completed”and “0.” However, both values are substantively equivalent because theyare both interpreted as successful statuses in the two schedulers 137.Therefore, the property object can translate the two values into asingle normalized value such as “Success,” a “completed,” “0,” andothers. Properties 404 may each include a name and a value. Generally,many properties in normalization policy 145 may be normalized.Accordingly, in some embodiments, property 404 may each also comprise amapping of the particular property value and the associated normalizedvalue. In certain embodiments, property object 404 includes a methodoperable to normalize the value or includes metadata associated with theparticular value type that allows subsequent modules to normalize thevalue. In other words, each property 404 operable to be normalized maybe a collection of tuple objects. For example, one tuple object maycomprises the property identifier, the property value, and the defaultnormalized value. In another example, one tuple object may comprise anidentifier of the operating environment 106, the property identifier,the property value, and the default normalized value. In a furtherexample, one tuple object may comprise the user ID or group ID, theproperty identifier, the property value, and the associated orcustomized normalized value. Of course, these examples and theassociated illustration are for readability purposes only. Normalizationpolicies 145 may be in any format and may include any suitable data.Moreover, job manager 130 may use any appropriate component or techniqueto normalize the data without departing from the scope of thedisclosure.

FIGS. 5A-F are example displays for presenting various normalizedproperties of heterogeneous jobs as executed in accordance with oneembodiment of system 100. It will be understood that illustrated webpages 116 a-116 f, respectively, are for example purposes only.Accordingly, GUI 116 may include or present data, such as normalized orraw job properties, in any format or descriptive language and each pagemay present any appropriate data in any layout without departing fromthe scope of the disclosure.

Turning to the illustrated embodiments, FIG. 5A illustrates an examplejob requirements or job properties view 116 a. In this view 116 a, theuser may be able to view or modify various properties of job 150 orjobset. In other words, job properties view 116 a is a graphicalrepresentation of the objects that can be included in the definition ofthe job. Job objects may include: job predecessor; job successor;triggers; calendar; VRM requirements; dataset predecessors; userrequirements; and network predecessors. The dialog may be a modelessframe that contains a context sensitive panel for displaying thegraphical view of the selected item's objects. This frame may contain apalette on the left side that has a list of objects that can be createdfor the selected object. On the right may be the graphical layout of theobjects for the selected item. Users may have the option to drag itemsfrom the palette and drop them onto the graphical layout. Dragging anddropping an object may create a new object, but the user often fills inthe properties for that object in the main view. Upon dropping theobject, an icon may appear in the graphical layout. Also, the main viewmay select the new object and display its properties so the user mayfill in any missing attributes. Until the user fills in requiredproperties, all icons representing the new object may have a graphicaldesign that alerts the user that the object is incomplete.

Accordingly, job properties view 116 a gives the user the ability todrag existing objects into the job properties view 116 a from the mainpanel's tree view. Job properties view 116 a may not allow invalidobjects to be dropped and the cursor may change to a “No” symbol tonotify the user. When a valid object is dropped, an icon may appear inthe job properties view 116 layout and the main view may select thedropped object and display its properties. Job properties view 116 a mayalways be locked onto the object that was selected when it was launched.Users may have the ability to select objects in the main view withoutjob properties view 116 a changing. When the user is finished changingthe requirements for job 150 or jobset, the applet may provide theoption to either close the dialog or change the job properties view 116a's selection to edit another object's requirements. Job properties view116 a may display a blank panel if the user deletes the selected job 150or jobset from the view. When the user selects an object in jobproperties view 116 a, the main view may select the same object anddisplay its properties.

FIG. 5B illustrates an example job status view 116 b. In certainembodiments, job status view 116 b consolidates the jobs that arefiltered for that particular view and displays associated properties. Ofcourse, this view may be customizable across the enterprise orindividually. In other words, the particular view may display propertiesas selected by the user. This view can be sorted by column (orproperty). The user is also allowed to scroll between sets of jobs whenthe number of jobs exceeds the window size set for the view. Also, theuser is allowed to jump directly into a specific set, the starting set,and the ending set. The order of the properties can also be defined.Often, job status view 116 b displays the normalized properties, opposedto the raw data. This allows the user to sort, filter, and otherwiseview heterogeneous jobs in a consistent interface. For example, thefirst two displayed jobs “testjob” and “WhereDidAllTheBoxJobsGo” may bea UNIX job and a mainframe job, respectively. Yet, view 116 b presents acommon property, “Success,” for both jobs after normalizing the nativevalues.

FIG. 5C provides an example overall view 116 c of all the various BSVs,to which the particular user has access, in list type view. For eachBSV, view 116 c shows the number of objects in various pre-definedstatuses. When user navigates through rows of the list view by pressingthe left mouse button or the up/down arrow keys in the keyboard, thetoolbar will show the corresponding enabled icons for the selected BSV.When there is a selected row and user sorts the rows, the toolbar iconswill be enabled/disabled according to the newly selected row objectafter the sort. If user right-clicks any row, a context menu will appearthat shows the same enabled menu items, and the toolbar icons will beenabled/disabled accordingly. As with the other views, view 116 c maydisplay or process the various properties after appropriate ones havebeen normalized.

FIGS. 5D, 5E, and 5F illustrates various graphical or tabular views (116d 116 e, and 116 f) of the various jobs and job properties. For example,the user may select a loaded BSV from the tree, resulting in the BSVdetails in multiple tabs in the right pane. In this case, this viewsummarizes the status of the jobs and jobsets included in this BSV andcan be displayed as a bar chart or pie chart. These charts show thenumber of jobs at different status. Each status is represented with acolor and this helps in understanding the overall health of the systemat a glance. The user can typically switch between these two chartstyles using the toolbar option. As with the other views, views 116 d116 e, and 116 f may each display or process the various propertiesafter appropriate ones have been normalized.

FIG. 6 is a flowchart illustrating an example method 600 for submittinga job 150 in one or more of a plurality of heterogeneous operatingenvironments 106 in accordance with one embodiment of the presentdisclosure. At a high level, method 600 includes receiving a jobsubmission from a user and executing job 150 in the appropriateoperating environment 106 (or operating environments 106). The followingdescription focuses on the operation of job manager 130 in performingmethod 600. But system 100 contemplates using any appropriatecombination and arrangement of logical elements implementing some or allof the described functionality.

Method 600 begins at step 602, where job manager 130 receives a jobrequest from the user, typically using client 104. But, as describedabove, the user may submit job request directly to server 102 withoutdeparting from the scope of method 600. The job request may comprise oneor more of the following types of jobs: an update job, a command, atask, or any other appropriate enterprise job or request. Next, at step604, job manager 130 authenticates the user. This authentication mayinclude verifying that the user can submit this particular type of job,can update the requested or associated data, or any other security orauthentication procedure or technique. Of course, while not illustrated,modules other than job manager 130 may perform this authentication andcommunicate the results to job manager 130. Job manager 130 thenidentifies a job object 140 using the received job request at step 606.For example, the job request may include a job identifier or otherpointer. In this example, job manager 130 queries the plurality of jobobjects 140 to determine the particular job object 140 associated withthe request based on the pointer. Once the appropriate job object 140 isidentified, Job manager 130 identifies operating environments 106 forthe job at step 608. As described above, in the case of a distributedjob, there may be more than one operating environment 106 associatedwith the job. Job manager 130 may identify the appropriate operatingenvironment 106 using any suitable technique. For example, job manager130 may determine the appropriate operating system to execute the job.In another example, job manager 130 may identify the location of thedata storage associated with the job request. In yet another example,job manager 130 may identify the appropriate virtual location forexecuting the job request. Next, at step 610, job manager 130 invokes ajob scheduler 137 in the identified operating environment 106. Once jobmanager 130 has invoked job scheduler, it may execute the job using theinvoked job scheduler 137 at step 612. It will be understood that thisexecution may include an immediate submission, adding the job to queueassociated with the invoked job scheduler, or any other appropriatetechnique.

FIG. 7 is a flowchart illustrating example method 700 for normalizingjob properties in accordance with one embodiment of the presentdisclosure. Generally, method 700 describes one example technique forjob manager 130 to receive one or more properties associated with a job,identify the appropriate mapping for the normalization of at least aportion of these properties, and communicating them to a particular useror application. It will be understood that method 700 is forillustration purposes only and that the described or similar techniquesmay be performed at any appropriate time, including concurrently,individually, or in combination. The following descriptions will focuson the operation of job manager 130 in performing this method. But, aswith the previous flowchart, system 100 contemplates using anyappropriate combination and arrangement of logical elements implementingsome or all of the described functionality.

Method 700 begins at step 702, where server 102 receives a statusrequest from a user, typically at client 104. Next, at step 704, jobmanager 130 loads a default normalization policy 145. Of course, jobmanager 130 may load the default normalization policy 145 at startup,initialization, or any at other appropriate time. At decisional step706, job manager 130 determines if the requesting user is associatedwith a user normalization policy 145. For example, job manager 130 mayparse the status request to identify the user ID. In another example,job manager 130 may store an alias for the requesting user for thevarious back-end operating environments 106. In yet another example, jobmanager may receive a user identifier from GUI 116 or another module.Once job manager 130 has sufficiently identified the appropriate user,job manager 130 loads the user normalization policy 145 at step 708 ifappropriate.

Once the one or more normalization policies 145 have been loaded oridentified, job manager 130 identifies a first job 150 associated withthe status request at step 710. Next, job manager 130 identifies a firstjob property for the identified job at step 712. For example, the jobproperty may be job status property object stored in server 102. Inanother example, job manager 130 may query the appropriate operatingenvironment 106 through an adapter 135. This job property may comprise astatus, name, output, or any other appropriate data or characteristic.At decisional step 714, job manager 130 determines if a data map existsfor the identified job property in the loaded user normalization policy145. If the map does not exist, then job manager 130 selects the datamapping from the default normalization policy 145 at step 718. If theuser normalization policy 145 does include the appropriate data map, thejob manager 130 selects, loads, or otherwise identifies the data map inuser normalization policy 145 at step 716. It will be understood thatjob manager 130 may select the data map using any appropriate techniquesuch as, for example, loading a job status property object based onproperty name, identifying an algorithm associated with the user, job,operating environment one of six, and property, or any other appropriatetechnique. Once the appropriate data mapping has been identified, jobmanager 130 normalizes the identified job property using the appropriatedata map at step 720.

Next, at decisional step 722, job manager 130 determines if there aremore properties associated with the particular job 150. If there are,then job manager 130 identifies the next job property for the particularjob at step 724 and processing returns to decisional step 714. Oncethere no more properties associated with the particular job 150, thenjob manager 130 determines if there are more jobs associated with thestatus request at decisional step 726. If there are more jobs, then jobmanager 130 identifies a next job 150 using the status request at step728 and processing returns to step 712. Once the status request has beenappropriately processed, then job manager 130 generates a presentationincluding the normalized properties at step 730. In certain embodiments,job manager 130 may identify the appropriate template and embed thenormalized properties in the template. In another embodiment, jobmanager 130 may identify a dynamic page already resident on theappropriate client 104. In this case, job manager 130 may encapsulatethe normalized properties in a presentation object for communication toclient 104. Next, at step 732, job manager 130 communicates thepresentation or presentation object to the requesting user at client104.

The preceding flowcharts and accompanying description illustrateexemplary methods 600 and 700. In short, system 100 contemplates usingany suitable technique for performing these and other tasks.Accordingly, many of the steps in these flowcharts may take placesimultaneously and/or in different orders than as shown. Moreover,system 100 may use methods with additional steps, fewer steps, and/ordifferent steps, so long as the methods remain appropriate.

Although this disclosure has been described in, terms of certainembodiments and generally associated methods, alterations andpermutations of these embodiments and methods will be apparent to thoseskilled in the art. Accordingly, the above description of exampleembodiments does not define or constrain this disclosure. Other changes,substitutions, and alterations are also possible without departing fromthe spirit and scope of this disclosure.

1. A job manager operable to: identify a property of a job in responseto a request from a user, the job associated with an operatingenvironment; normalize the property of the job; and present thenormalized property of the job to the user.
 2. The job manager of claim1, the property comprising a first property, the job comprising a firstjob, and the operating environment comprising a first operatingenvironment, the job manager further operable to: identify a secondproperty of a second job based on the request from the user, the secondjob associated with a second operating environment; normalize the secondproperty of the second job; and present the normalized second propertyof the second job to the user.
 3. The job manager of claim 2, the firstproperty and the second property comprising different values and thenormalized first property and the normalized second property comprisingidentical values.
 4. The job manager of claim 2, the first operatingenvironment and second operating environment each executing at leastpartially different operating systems.
 5. The job manager of claim 4,the first operating environment comprising a UNIX environment.
 6. Thejob manager of claim 4, the first operating environment comprising aMainframe operating system.
 7. The job manager of claim 4, the jobmanager executing in the first operating environment and the firstoperating environment comprising a Windows operating system.
 8. The jobmanager of claim 1, wherein the job manager operable to normalize theproperty comprises the job manager operable to normalize the propertybased, at least in part, on an enterprise wide policy.
 9. The jobmanager of claim 1, wherein the job manager operable to normalize theproperty comprises the job manager operable to normalize the propertybased, at least in part, on a customizable policy associated with theuser.
 10. The job manager of claim 1, the property comprising a firstproperty, the job comprising a first job, the operating environmentcomprising a first operating environment, and the user comprising afirst user, the job manager further operable to: identify a secondproperty of a second job based on the request from the user, the secondjob associated with a second operating environment; normalize the secondproperty of the second job; and present the normalized second propertyof the second job to a second user.
 11. The job manager of claim 10,wherein the job manager operable to normalize the first propertycomprises the job manager operable to normalize the first propertybased, at least in part, on a first policy associated with the firstuser and wherein the job manager operable to normalize the secondproperty comprises the job manager operable to normalize the secondproperty based, at least in part, on a second policy associated with thesecond user.
 12. The job manager of claim 1, the job selected from oneof the following: a command object; a process object; and a task object.13. The job manager of claim 1, the property comprising a statusproperty and the normalized status property selected from one of thefollowing: running; failure; waiting; success; cancel; restart; on hold;late to start; running late; inactive; and unknown.
 14. The job managerof claim 1, the job comprising one of a plurality of jobs, each jobassociated with one of a plurality of operating environments andassociated with at least one normalized property.
 15. The job manager ofclaim 14 further operable to sort the plurality of jobs based, at leastin part, on one of the normalized properties.
 16. The job manager ofclaim 14 further operable to: receive a search request from the user,the search request associated with one of the normalized properties; andidentify one or of the plurality of jobs based, at least in part, on thesearch request.
 17. The job manager of claim 14 further operable togenerate a plurality of metrics for the plurality of jobs, at least oneof the metrics associated with one of the normalized properties.
 18. Amethod for normalizing job properties comprising: identifying a propertyof a job in response to a request from a user, the job associated withan operating environment; normalizing the property of the job; andpresenting the normalized property of the job to the user.
 19. Themethod of claim 18, the property comprising a first property, the jobcomprising a first job, and the operating environment comprising a firstoperating environment, the method further comprising: identifying asecond property of a second job based on a request from the user, thesecond job associated with a second operating environment; normalizingthe second property of the second job; and presenting the normalizedsecond property of the second job to the user.
 20. The method of claim19, the first property and the second property comprising differentvalues and the normalized first property and the normalized secondproperty comprising identical values.
 21. The method of claim 19, thefirst operating environment and second operating environment eachexecuting at least partially different operating systems.
 22. The methodof claim 21, the first operating environment executing a Mainframeoperating system.
 23. The method of claim 18, wherein the job manageroperable to normalize the property comprises the job manager operable tonormalize the property based, at least in part, on an enterprise widepolicy.
 24. The method of claim 18, wherein the job manager operable tonormalize the property comprises the job manager operable to normalizethe property based, at least in part, on a policy associated with theuser.
 25. The method of claim 24, the policy operable to be customizedby the user.
 26. The method of claim 18, the property comprising a firstproperty, the job comprising a first job, the operating environmentcomprising a first operating environment, and the user comprising afirst user, the method further comprising: identifying a second propertyof a second job based on the request from the user, the second jobassociated with a second operating environment; normalizing the secondproperty of the second job; and presenting the normalized secondproperty of the second job to a second user.
 27. The method of claim 26,wherein the job manager operable to normalize the first propertycomprises the job manager operable to normalize the first propertybased, at least in part, on a first policy associated with the firstuser and wherein the job manager operable to normalize the secondproperty comprises the job manager operable to normalize the secondproperty based, at least in part, on a second policy associated with thesecond user.
 28. The method of claim 26 further comprising sorting thefirst and second jobs based, at least in part, on one of the normalizedproperties.
 29. The method of claim 26 further comprising: receiving asearch request from the user, the search request associated with one ofthe normalized properties; and identifying one of the plurality of jobsbased, at least in part, on the search request.
 30. The method of claim26 further comprising generating a plurality of metrics for theplurality of jobs, at least one of the metrics associated with one ofthe normalized properties.
 31. The method of claim 18, the job selectedfrom one of the following: a command object; a process object; and atask object.
 32. The method of claim 18, the property comprising astatus property and the normalized status property selected from one ofthe following: running; failure; waiting; success; cancel; restart; onhold; late to start; running late; inactive; and unknown.
 33. A systemfor normalizing job properties in an enterprise comprising: memorystoring a plurality of normalization policies; and one or moreprocessors operable to: identify a property of a job in response to arequest from a user, the job associated with an operating environment;normalize the property of the job based, at least in part, on one of thenormalization policies; and present the normalized property of the jobto a user.
 34. The system of claim 33, the property comprising a firstproperty, the job comprising a first job, and the operating environmentcomprising a first operating environment, the one or more processorsfurther operable to: identify a second property of a second job based onthe request from the user, the second job associated with a secondoperating environment; normalize the second property of the second job;and present the normalized second property of the second job to theuser.
 35. The system of claim 34, the first property and the secondproperty comprising different values and the normalized first propertyand the normalized second property comprising identical values.
 36. Thesystem of claim 34, the first operating environment and second operatingenvironment each executing at least partially different operatingsystems.
 37. The system of claim 36, the first operating environmentexecuting UNIX.
 38. The system of claim 36, the one or more processorsexecuting the first operating environment.
 39. The system of claim 33,the normalization policy comprising an enterprise wide policy.
 40. Thesystem of claim 33, the job selected from one of the following: acommand object; a process object; and a task object.
 41. The system ofclaim 33, the property comprising a status property and the normalizedstatus property selected from one of the following: running; failure;waiting; success; cancel; restart; on hold; late to start; running late;inactive; and unknown.